DebugCollector: first class file archival #9555
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Author
|
Marking this draft because I still want to do some testing on a4x2 or a racklette. |
Collaborator
Author
|
I deployed this to
Regarding sled 14, I did briefly see the process core dump here: As expected, that disappeared and the archived copy showed up: On the sled where I induced a system panic: In terms of log files: back on sled 14: |
Collaborator
Author
|
I started a VM and was surprised to immediately see some rotated files in the debug dataset, but it turns out that yes, cron had run logadm despite this zone being only minutes old: Out in the GZ: What I've yet to confirm:
|
Collaborator
Author
|
I tried restarting sled-agent on sled 14, expecting to see that the restart would bounce control plane zones and archive their live log files, but I don't seem to see the live log files archived. I need to do more digging on that. |
Collaborator
Author
|
I watched the global zone files get rotated as expected: then a few minutes later: |
jgallagher
reviewed
Jan 13, 2026
Contributor
jgallagher
left a comment
jgallagher
left a comment
There was a problem hiding this comment.
LGTM - happy to review again once this is out of draft.
|
|
||
| #[derive(Debug, Error)] | ||
| #[error("string is not a valid filename (has slashes or is '.' or '..')")] | ||
| pub(crate) struct BadFilename; |
Contributor
There was a problem hiding this comment.
Nit - maybe include the invalid filename itself?
|
|
||
| tokio::io::copy(&mut src_f, &mut dest_f).await?; | ||
|
|
||
| dest_f.sync_all().await?; |
Contributor
There was a problem hiding this comment.
Do we also need to sync dest_f's parent directory?
Collaborator
Author
There was a problem hiding this comment.
This code hasn't changed, so it wouldn't be a regression, but I did go ahead and add this fsync.
Collaborator
Author
|
I've discovered some minor confusion in this PR. For some reason that I did not write down, at some point I concluded incorrectly that Sled Agent writes kernel crash dumps to the "crash" dataset on the M.2. I suspect I concluded this because on dogfood, sled 13 has two crash dumps there: If this were the normal process, then I would expect that both the old code (in But that's not what happens. The block comment: omicron/sled-agent/config-reconciler/src/debug_collector/worker.rs Lines 49 to 80 in e6961bc seems to reflect what really happens, which is that we have Edit: you might wonder why sled 13 still has those dumps in that directory, instead of them being archived and deleted? The answer is that sled agent doesn't know about any U.2s because the control plane hasn't been initialized there because it hasn't been part of the control plane in years. Commit 71e24bc updates this PR to remove a crash dump from the test data. @jgallagher does all this make sense to you? I'm just a little nervous because if I'm wrong, then I'm afraid the new code would clobber crash dumps where the old one wouldn't have. But I don't think that's the case based on my current understanding. (I'm still not sure how a crash dump got into a cores dataset on that one sled.) |
Contributor
Yeah, that all makes sense.
I don't think that sled has ever been a part of the (current) dogfood control plane; otherwise we'd have an entry in |
Collaborator
Author
|
An important goal of this change is that the new automated tests cover much more of the end-to-end archival path than before. Still, I wanted to do some manual testing to make sure the last bits are wired up correctly. Here a summary of my manual test plan:
I installed e2a09c6 onto Core dump flowI induced a few core dumps on sled 14: As expected, they showed up in the cores dataset on an M2: A few seconds later, they were gone from there and archived onto a debug dataset Crash dump / sled reboot flowI induced a panic on sled 15: On boot, when sled agent started up, it appeared idle (not starting zones), but it was actually running savecore. Using That eventually finished: All of this happens before time is sync'd (since it hasn't started any zones, including the NTP zone). But a few minutes later, time did sync as expected. A little while after this, I had these log files: File Log filesTo smoke check log archival without tying up a racklette for hours, I installed e2a09c6 in a4x2 and let it run overnight. I've got: We've got archived global zone log files: and their originals are gone: The counts of entries in the non-global-zone directories above show that we have hundreds of log files for these zones, including the switch zone. To give a sense of it: There are no old rotated log files in the zone: Same for an Omicron zone: Similarly, these zones have no rotated syslog files still in them: though we do have archived ones: |
jgallagher
approved these changes
Jan 14, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a more first-class file archival mechanism inside the debug collector within sled agent. The reason I did this is that in the past when I wanted to modify the files that Sled Agent collects, I found it tricky to do because:
Altogether I basically felt like even when making a pretty small change, you essentially had to test in a real deployment, which is a much slower dev workflow than it needs to be (and it'd be very easy to break without breaking CI).
This is coming up because I'm planning to implement RFD 613 Debug Dropbox shortly.
After this PR, there's a new
file_archivermodule:rulessubmodule) that describe what files to collect. I hope it's easy to add new things to this.It's arguably overengineered at this point but I'm hopeful that this will make it a lot easier to augment the set of files that get archived in this way.
As a first step, I tried to preserve the existing behavior as much as possible. There are several oddities that we might want to fix in follow-up work:
crash dumps andcore files. This would be buggy but not a huge deal for core files because their names are pretty unusual (they have pids and execnames and zonenames in them), but it seems likely to result in at most one crash dump kept per sled ever since they'll all be called.vmdump.0something.mtimeinstead ofsomething.log.mtimethe way that rotated log files do. This isn't a huge deal but does breakoxlog(oxlog does not find archived live log files #9271). I'm not sure what we should do here. We could use the same convention but then we'd lose the distinction between live vs. rotated log files. I'm not sure if that's important.